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IPv6 Support for Generic Routing Encapsulation (GRE) 
Abstract 
Generic Routing Encapsulation (GRE) can be used to carry any network- 
layer payload protocol over any network-layer delivery protocol. 
Currently, GRE procedures are specified for IPv4, used as either the 
payload or delivery protocol. However, GRE procedures are not 


specified for IPv6. 


This document specifies GRE procedures for IPv6, used as either the 
payload or delivery protocol. 


Status of This Memo 
This is an Internet Standards Track document. 
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Introduction 


Generic Routing Encapsulation (GRE) [RFC2784] [RFC2890] can be used 
to carry any network-layer payload protocol over any network-layer 
delivery protocol. Currently, GRE procedures are specified for IPv4 
[RFC791], used as either the payload or delivery protocol. However, 
GRE procedures are not specified for IPv6 [RFC2460]. 


This document specifies GRE procedures for IPv6, used as either the 
payload or delivery protocol. Like RFC 2784, this document describes 
how GRE has been implemented by several vendors. 


1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


.2. Terminology 


The following terms are used in this document: 


o GRE delivery header: An IPv4 or IPv6 header whose source address 
represents the GRE ingress node and whose destination address 
represents the GRE egress node. The GRE delivery header 
encapsulates a GRE header. 


o GRE header: The GRE protocol header. The GRE header is 
encapsulated in the GRE delivery header and encapsulates the GRE 
payload. 


o GRE payload: A network-layer packet that is encapsulated by the 
GRE header. 


o GRE overhead: The combined size of the GRE delivery header and the 
GRE header, measured in octets. 


o Path MTU (PMTU): The minimum MTU of all the links in a path 
between a source node and a destination node. If the source and 
destination node are connected through Equal-Cost Multipath 
(ECMP), the PMTU is equal to the minimum link MTU of all links 
contributing to the multipath. 


o Path MTU Discovery (PMTUD): A procedure for dynamically 
discovering the PMTU between two nodes on the Internet. PMTUD 
procedures for IPv6 are defined in [RFC1981]. 
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o GRE MTU (GMTU): The maximum transmission unit, i.e., maximum 
packet size in octets, that can be conveyed over a GRE tunnel 
without fragmentation of any kind. The GMTU is equal to the PMTU 
associated with the path between the GRE ingress and the GRE 
egress, minus the GRE overhead. 


2. GRE Header Fields 


This document does not change the GRE header format or any behaviors 
specified by RFC 2784 or RFC 2890. 


2.1. Checksum Present 


The GRE ingress node SHOULD set the Checksum Present field in the GRE 
header to zero. However, implementations MAY support a configuration 
option that causes the GRE ingress node to set the Checksum Present 
field to one. 


As per Section 2.2 of RFC 2784, the GRE egress node uses the Checksum 
Present field to calculate the length of the GRE header. If the 
Checksum Present field is set to one, the GRE egress node MUST use 
the GRE Checksum to verify the integrity of the GRE header and 
payload. 


Setting the Checksum Present field to zero reduces the computational 
cost of GRE encapsulation and decapsulation. In many cases, the GRE 
Checksum is partially redundant with other checksums. For example: 


o If the payload protocol is IPv4, the IPv4 header is protected by 
both the GRE Checksum and the IPv4 Checksum. 


o If the payload carries TCP [RFC793], the TCP pseudo header, TCP 
header, and TCP payload are protected by both the GRE Checksum and 
TCP Checksum. 


o If the payload carries UDP [RFC768], the UDP pseudo header, UDP 
header, and UDP payload are protected by both the GRE Checksum and 
UDP Checksum. 


However, if the GRE Checksum Present field is set to zero, the GRE 

header is not protected by any checksum. Furthermore, depending on 
which of the above-mentioned conditions are true, selected portions 
of the GRE payload will not be protected by any checksum. 


Network operators should evaluate risk factors in their networks and 
configure GRE ingress nodes appropriately. 
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3. IPv6 as GRE Payload 


The following considerations apply to GRE tunnels that carry an IPv6 
payload. 


3.1. GRE Protocol Type Considerations 


The Protocol Type field in the GRE header MUST be set to Ether Type 
[RFC7042] Ox86DD (IPv6). 


3.2. MTU Considerations 


A GRE tunnel MUST be able to carry a 1280-octet IPv6 packet from 
ingress to egress, without fragmenting the payload packet. All GRE 
tunnels with a GMTU of 1280 octets or greater satisfy this 
requirement. GRE tunnels that can fragment and reassemble delivery 
packets also satisfy this requirement, regardless of their GMTU. 
However, the ability to fragment and reassemble delivery packets is 
not a requirement of this specification. This specification requires 
only that GRE ingress nodes refrain from activating GRE tunnels that 
do not satisfy the above-mentioned requirement. 


Before activating a GRE tunnel and periodically thereafter, the GRE 
ingress node MUST verify the tunnel’s ability to carry a 1280-octet 
IPv6 payload packet from ingress to egress, without fragmenting the 
payload. Having executed those procedures, the GRE ingress node MUST 
activate or deactivate the tunnel accordingly. 


Implementation details regarding the above-mentioned verification 
procedures are beyond the scope of this document. However, a GRE 
ingress node can verify tunnel capabilities by sending a 1280-octet 
IPv6 packet addressed to itself through the tunnel under test. 


Many existing implementations [RFC7588] do not support the above- 
mentioned verification procedures. Unless deployed in environments 
where the GMTU is guaranteed to be greater than 1280, these 
implementations MUST be configured so that the GRE endpoints can 
fragment and reassemble the GRE delivery packet. 


3.3. Fragmentation Considerations 


When the GRE ingress receives an IPv6 payload packet whose length is 
less than or equal to the GMTU, it can encapsulate and forward the 
packet without fragmentation of any kind. In this case, the GRE 
ingress router MUST NOT fragment the payload or delivery packets. 
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When the GRE ingress receives an IPv6 payload packet whose length is 
greater than the GMTU, and the GMTU is greater than or equal to 1280 
octets, the GRE ingress router MUST: 


o discard the IPv6 payload packet 
o send an ICMPv6 Packet Too Big (PTB) [RFC4443] message to the IPv6 


payload packet source. The MTU field in the ICMPv6 PTB message is 
set to the GMTU. 


When the GRE ingress receives an IPv6 payload packet whose length is 
greater than the GMTIU, and the GMTU is less than 1280 octets, the GRE 
ingress router MUST: 


o encapsulate the entire IPv6 packet in a single GRE header and IP 
delivery header 


o fragment the delivery header, so that it can be reassembled by the 
GRE egress 


4. IPv6 as GRE Delivery Protocol 


The following considerations apply when the delivery protocol is 
IPv6. 


4.1. Next Header Considerations 


When the GRE delivery protocol is IPv6, the GRE header MAY 
immediately follow the GRE delivery header. Alternatively, IPv6 
extension headers MAY be inserted between the GRE delivery header and 
the GRE header. 


If the GRE header immediately follows the GRE delivery header, the 
Next Header field in the IPv6 header of the GRE delivery packet MUST 
be set to 47. If extension headers are inserted between the GRE 
delivery header and the GRE header, the Next Header field in the last 
IPv6 extension header MUST be set to 47. 


4.2. Checksum Considerations 


As stated in [RFC2784], the GRE header can contain a checksum. If 
present, the GRE header checksum can be used to detect corruption of 
the GRE header and GRE payload. 


The GRE header checksum cannot be used to detect corruption of the 
IPv6 delivery header. Furthermore, the IPv6 delivery header does not 
contain a checksum of its own. Therefore, no available checksum can 
be used to detect corruption of the IPv6 delivery header. 
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In one failure scenario, the destination address in the IPv6 delivery 
header is corrupted. As a result, the IPv6 delivery packet is 
delivered to a node other than the intended GRE egress node. 
Depending upon the state and configuration of that node, it will 
either: 


a. Drop the packet 


b. Decapsulate the payload and forward it to its intended 
destination 


c. Decapsulate the payload and forward it to a node other than its 
intended destination. 


Behaviors a) and b) are acceptable. Behavior c) is not acceptable. 
Behavior c) is possible only when the following conditions are true: 


1. The intended GRE egress node is a Virtual Private Network (VPN) 
Provider Edge (PE) router. 


2. The node to which the GRE delivery packet is mistakenly delivered 
is also a VPN PE router. 


3. VPNs are attached to both of the above-mentioned nodes. At least 
two of these VPN’s number hosts are from a non-unique (e.g., 
[RFC1918]) address space. 


4. The intended GRE egress node maintains state that causes it to 
decapsulate the packet and forward the payload to its intended 
destination 


5. The node to which the GRE delivery packet is mistakenly delivered 
maintains state that causes it to decapsulate the packet and 
forward the payload to an identically numbered host in another 
VPN. 


While the failure scenario described above is extremely unlikely, a 
single misdelivered packet can adversely impact applications running 
on the node to which the packet is misdelivered. Furthermore, 
leaking packets across VPN boundaries also constitutes a security 
breach. The risk associated with behavior c) could be mitigated with 
end-to-end authentication of the payload. 


Before deploying GRE over IPv6, network operators should consider the 
likelihood of behavior c) in their network. GRE over IPv6 MUST NOT 
be deployed other than where the network operator deems the risk 
associated with behavior c) to be acceptable. 
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4.3. MTU Considerations 


By default, the GRE ingress node cannot fragment the IPv6 delivery 
header. However, implementations MAY support an optional 
configuration in which the GRE ingress node can fragment the IPv6 
delivery header. 


Also by default, the GRE egress node cannot reassemble the IPv6 
delivery header. However, implementations MAY support an optional 
configuration in which the GRE egress node can reassemble the IPv6 
delivery header. 


5. Security Considerations 


The Security Considerations section of [RFC4023] identifies threats 
encountered when MPLS is delivered over GRE. These threats apply to 
any GRE payload. As stated in RFC 4023, these various threats can be 
mitigated through options such as authenticating and/or encrypting 
the delivery packet using IPsec [RFC4301]. Alternatively, when the 
payload is IPv6, these threats can also be mitigated by 
authenticating and/or encrypting the payload using IPsec, instead of 
the delivery packet. Otherwise, the current specification introduces 
no security considerations beyond those mentioned in RFC 2784. 


More generally, security considerations for IPv6 are discussed in 


[RFC4942]. Operational security for IPv6 is discussed in [OPSEC-V6], 
and security concerns for tunnels in general are discussed in 
[RFC6169]. 
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